1. Field of the Invention
Embodiments of the present invention generally relate to storage management, and more particularly, to software used in storage management.
2. Description of the Related Art
In the past, large organizations relied heavily on parallel Small Computer System Interface (SCSI) technology to provide the performance required for their enterprise data storage needs. More recently, organizations are recognizing that the restrictions imposed by SCSI architecture are too costly for SCSI to continue as a viable enterprise storage solution. Such restrictions include the following:                SCSI disk arrays must be located no more than 25 meters from the host server;        The parallel SCSI bus is susceptible to data errors resulting from slight timing discrepancies or improper port termination; and        SCSI array servicing frequently requires downtime for every disk in the array.        
One solution has been to create technology that enables storage arrays to reside directly in the network, where disk accesses may be made directly rather than through the server's SCSI connection. This network-attached storage (NAS) model eliminates SCSI's restrictive cable distance, signal timing, and termination requirements. However, this model adds a significant load to the network, which frequently is already starved for bandwidth. Gigabit Ethernet technology only alleviates this bottleneck for the short term, and thus, a more elegant solution is desirable.
The storage area network (SAN) model places storage on its own dedicated network, removing data storage from both the server-to-disk SCSI bus and the main user network. This dedicated network most commonly uses Fiber Channel technology, a versatile, high-speed transport. The SAN includes one or more hosts that provide a point of interface with local area network (LAN) users, as well as (in the case of large SANs) one or more fabric switches, SAN hubs and other devices to accommodate a large number of storage devices. The hardware (e.g. fabric switches, hubs, bridges, routers, cables, etc.) that connects workstations and servers to storage devices in a SAN is referred to as a “fabric.” The connectivity between a host and a storage device is typically defined as a route. The SAN fabric may enable server-to-storage device connectivity through Fiber Channel switching technology to a wide range of servers and storage devices. The versatility of the SAN model enables organizations to perform tasks that were previously difficult to implement, such as LAN-free and server-free tape backup, storage leasing, and full-motion video services.
Each SAN device, such as a host bus adapter, is generally tagged with a unique identifier, such as a world wide name (WWN), which is a 64-bit identifier. The identifier is generally burned on the device during manufacture. The identifier is generally used to assist with SAN management, including compartmentalization, authorization and securitization. The identifier is also used to associate the device with various logical relationships, such as zones and logical unit number (LUN) masks.
When a device fails and is replaced with a new device, the logical relationships associated with the failed device is modified or reconfigured with an identifier associated with the new device. This can be an arduous task for the user or system administrator, considering that the new identifier may have to be entered manually one digit at a time, each logical relationship may be with a different entity/device, each entity/device may be from a different vendor, and each vendor may require its own proprietary configuration tool or may require access through a proprietary application programming interface (API). For example, a host bus adapter (HBA) that is zoned with a BROCADE® switch may only be configured using BROCADE's proprietary switch configuration tool or a tool based on Brocade's proprietary API's. Likewise, an HBA that is LUN masked with an EMC® array may only be configured using EMC's proprietary array configuration tool or a tool based on EMC's proprietary API's. In this manner, the user is required to use a number of different configuration tools to reconfigure the logical relationships with the new device identifier. As a result, modifying or reconfiguring logical relationships of the failed device with the new device identifier may become a tedious and error-prone task.
Therefore, a need exists for a method and apparatus to automatically modify the logical relationships of the failed device with the new device identifier.